2016-01-18 - 24193 - Service Request - 2016 Order Fulfillment and HR - Week ending April 29 #ProductionBreakFix #SDSupportBilling #DailyProductionSDFISupport2016 #SDFI #FIMMSD #EDISD
2016-01-18 - 24193 - Service Request - 2016 Order Fulfillment and HR
Problem Summary
All supporting activities that are less than 4 hours in 2016 are updated in this sheet.
Admin Info
| Purpose |
All supporting activities that are less than 4 hours in 2016 are updated in this sheet. |
| Requested by |
Jeffrey Mau |
| Issue Date |
04/25/2016 - 04/29/2016 |
| Resolved by |
Surya/Deepak/Siba/Raghav |
| Resolved Date |
04/29/2016 |
| Document Status |
Completed |
Detailed Problem Description
(Include Screen Shots if required )1. It looks like the new packing step in yesterday's delivery creation job failed....can you please take a look and determine why?
NA_SD_DELV_CREATE
2. When you get a chance can you look at this order we are unable to do the ucc pack it just keeps on running So# 3016104 Del # 83244622 Footlocker.
3. Can you provide me an effort estimate for the following development in the sales order?
At Hot Market, our customers tend to request that their shipping carrier be modified on an order-by-order basis. To do so, customer service modifies the Customer Group 2 value at the sales order header. If they are changing carrier (for example, from FedEx to UPS), they also need to modify the account which is held in the Header-Texts. We are considering the idea of a user-exit which would not allow the user to change the carrier type unless the account has already been modified. Or perhaps if they do not match, then on-save, we make the document incomplete. We would want to setup a custom table in which the carrier types and validation values are stored and checked from (ex. if the carrier is FedEx, then the length of the account must be 9 digits, and would start with a specific number).
- No, I do not believe the carrier determination is handling this...because the Hot Market team has stated they consistently drop deliveries to Menlo with an invalid account # / carrier code combination
- The header text (account #) is driven by master data, but can be overwritten based on the customer's request (this occurs a lot at Hot Market)
- The table would likely include the carrier code, length of account #, and possibly a set of digits it should start with. Any carrier code that is not maintained in the table should not throw any errors or in-completions.
- We could look at augmenting carrier determination with this validation...if that makes the most sense.
- The way I envision the validation would be a table as follows (it turns out, we cannot use a validation on the first character in the account #s, because each carrier does not have a specific number or numbers they always start with)
- No change logs needed on the table
- The users absolutely could change either the customer group 2 (carrier) field, or modify the text manually. We'd have to develop a solution around this situation of possible extra spaces, etc.
We are just looking for a high-level estimate. Depending on the effort, we might want to use ABAP, or we might want to build a Crystal report. Once we have your estimate, we can dive deeper into the finalized design.
Solution Analysis and Recommendations
(Include Screen Shots if required)1 & 2. SO 3016104 is a cross dock order and the caselot quantity text id (run size ratio) on the item had a text formatting issue. The run-size ratio usually is maintained in a single row but in this case it appeared in multiple rows which program didn't identify and short dumped.
Wrong format
Right format
The same delivery was found in the short dump detailed analysis and could be the potential reason for the short dump.
3. Here are my thoughts -
- Does carrier determination not handle this requirement where the header text remains unchanged but the carrier updates based on the shipping point and weight?
- How is the header text determined today - master data or is it possible that it could be maintained manually also at the time of creation?
- Do we need to activate the change logs on the table; will the values in the table be unique - one carrier has single or multiple validation values; will there be any key field in addition to the two fields?
- Carrier determination doesn't change header text - it either deletes it or leaves it alone based on the flag in the Z table.
Can't we simply add the two address text fields to this table and use them for validating the sales orders? Let me know if there are any concerns?
- I assume a combination of carrier - header text will be unique or could there be multiple?
- Do we need change logs activated on the table?
- Manual changes of the header text could be complicated - when the match is made the program checks would be done for the exact string. An additional space could make a difference? The best way is to maintain the entry in the table and then let the system copy. However, these needs to be verified in debug. Would you like us check on this?
| Strategy |
High Level Estimate |
Notes |
|
60hrs |
No change logs/validations required on the table |
The effort estimate may differ based on the actual requirements and solution design and test plant.
Resolution
1 & 2. The run size ratio was updated at the grid level for both the items and the delivery packed successfully.
Release Information
Provide link here to Release Notes if Technical Objects were changed